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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 9/17/2007 appealing from the Office action mailed 
1/23/2006. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The following are the related appeals, interferences, and judicial proceedings known to 
the examiner which may be related to, directly affect or be directly affected by or have a bearing 
on the Board's decision in the pending appeal: 

Co-pending application number 10/072597 before the BPAL 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6,898,706 VENKATESAN ET AL. 05-2005 
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(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 1-14 are rejected under 35 U.S.C. 102(e) as being anticipated by Venkatesan et al. 
(hereinafter Venkatesan), US 6,898,706 Bl. 

As per the following claims, Venkatesan discloses : 
1 A method for deliver of a license-managed toolset for creating a license-managed software 
product, the method comprising the step of: 

(a) providing an authorization process, the authorization process including the steps of: 

(i) creating a first public and private key pair for a software publisher (fig 7, step 800), 

(ii) creating a second public and private key pair for a software program, at least one of 
the second private and public keys is digitally signed by the first private key of the 
software publisher (fig 7, step 800), 

(iii) creating an authorization program for the software program, and embedding a copy 
of the first and second public keys in the authorization program (fig 7, step 850), 

(iv) combining the authorization program with a software program, such that when the 
software program is invoked on a computer, the authorization program obtains a license 
for the software program by (fig 7, publisher, authority and client): 

(1) creating a license request (fig 8, 860 license request via link), 

(2) encrypting the license request using the second public key (fig 8, 870 encrypts 
fingerprint), 

(3) transmitting the encrypted license request to a key authority (fig 8, 340), 
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(4) receiving an encrypted license from the key authority, wherein the license 
includes license terms (fig 7, license download to each client), and 

(5) decrypting the license using the first public key, such that the license terms are 
used to control use of the software program (fig 7, step 1300); 

(b) implementing the authorization process in a software toolset that is provided by a 
toolset publisher, wherein when the authorization process is invoked in the software toolset, the 
toolset publisher is the publisher in the authorization process and the software toolset is the 
software program in the authorization process (fig 7, step 1400), and 

(c) implementing the authorization process in a software product that is provided by a 
publisher of the software product using the software toolset, wherein when the authorization 
process is invoked in the software product, the publisher of the software product is the publisher 
in the authorization process and the software product is the software program in the authorization 
process, whereby both the software toolset and the software product use the same authorization 
process to obtain respective licenses (figure 5, publisher-client authorization process). 

2 The method of claim 1 further includes the step of transferring the first and second private keys 
to a key authority for receiving license requests and generating licenses (fig 8, watermarking 
authority 340). 

3 The method of claim 1 fiirther includes the step of including product and customer information 
within the license request and license documents (fig 11, CID, PID, steps 1115, 1 122). 
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4 The method of claim 1 further includes the step of associating the license request with a 
financial transaction, and incorporating financial transaction information within the license (fig 
1 1 , step 1115 payment information 1 122 license generation). 

5 The method of claim 1 fiuther includes the steps of: (a) assigning a publisher ID to the 
publisher, (b) embedding the publisher ID within the authorization program, (c) including the 
publisher ID within the license, and (d) comparing the embedded publisher ID with the publisher 
ID within the license to verify the publisher of the software program to be authorized has 
generated the license (fig 11, step 1 122). 

6 The method of claim 1 fiirther including the steps of: (a) generating a machine fingerprint 
within the authorization process, (b) incorporating the machine fingerprint within the license 
request, (c) incorporating the machine fingerprint within the license terms, and (d) using by the 
authorization program the machine fingerprint to prevent use of the software product on a 
different machine than the one which made the license request (fig 11, step 1 122). 

7 A method for deliver of a license-managed toolset for creating a license-managed software 
product, the method comprising the step of: 

(a) providing an authorization process, the authorization process including the steps of: 
(i) creating a first public and private key pair for a software publisher, and creating a first 
certificate with the public key using a certificate authority (column 13, lines 18-34), (ii) creating 
a second public and private key pair for a software program, and creating a second certificate 
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with the software publisher private key, at least one of the second private and public keys is 
digitally signed by the first private key of the software publisher (columnl3, lines 25-34), (iii) 
creating an authorization program for the software program, and embedding a copy of the first 
and second certificates and second private key in the authorization program (column 13, '35-48), 
(iv) combining the authorization program with a software program, such that when the software 
program is invoked on a computer, the authorization program obtains a license for the software 
program by: (1) creating a formatted license request, (2) signing the formatted license request 
using the second public key, (3) transmitting the formatted signed license request to a key 
authority, (4) receiving an signed formatted license fi'om the key authority, wherein the license 
includes license terms, and (5) validating the license using the first certificate, such that the 
license terms are used to control use of the software program (fig 7 and as detailed in the above 
rejection of claim 1); 

(b) implementing the authorization process in the software toolset that is provided by a 
toolset publisher, wherein when the authorization process is invoked in the software toolset, the 
toolset publisher is the publisher in the authorization process and the software toolset is the 
software program in the authorization process (fig 7, 1400), and 

(c) implementing the authorization process in the software product that is provided by a . 
publisher of the software product using the software toolset, wherein when the authorization 
process is invoked in the software product, the publisher of the software product is the publisher 
in the authorization process and the software product is the software program in the authorization 
process, whereby both the software toolset and the software product use the same authorization 
process to obtain respective licenses (fig 5, publisher-client authorization process). 
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8 The method of claim 7 further includes the step of including product and customer information 
within the license request and license documents (see claim 3 above). 

9 The method of claim 7 further includes the step of associating the license request with a 
financial transaction, and incorporating financial transaction information within the license (see 
claim 4 above). 

10 The method of claim 7 further includes the step of formatting the license request and license 
using a proposed signed XML document format (column 11, lines 1-23, note that XML encoding 
may occur within HTML content; XML DTD describes a subset of HTML 4.0 for embedded use 
within other XML). 

1 1 The method of claim 7 further includes the step of generating the first public and private key 
pair for the software product publisher during the authorization process for the toolset, using the 
steps of: (a) creating the first public and private key pair for the software publisher prior to using 
the authorization process for the toolset; (b) including the public key within the license request 
document in the form of a certificate request; (c) receiving the certificate within the license 
document, and (d) using the received certificate in conjunction with the private key as the first 
key pair in the authorization process for the software product (see process in fig 5 and as detailed 
above rejected claims). 
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12 The method of claim 7 further includes the step of transferring the first and second private 
keys and certificates to a key authority for receiving license requests and generating licenses (fig 
8, step 900 watermarking authority 340). 

13 The method of claim 7 further includes the steps of: (a) assigning a publisher ID to tiie 
publisher, (b) including the publisher ID within the publisher certificate, included within the 
software product license, (c) embedding the publisher ID within the authorization program, (d) 
comparing the embedded publisher ID with the publisher ID within the certificate to verify the 
publisher of the software program to be authorized has generated the license (fig 11, steps 1115, 
1122). 

14 The method of claim 7 further including the steps of: (a) generating a machine fingerprint 
v^thin the authorization process, (b) incorporating the machine fingerprint within the license 
request, (c) incorporating the machine fingerprint within the license terms, and (d) using by the 
authorization program the machine fingerprint to prevent use of the software product on a 
different machine than the one which made the license request (fig 11, steps 1 1 15, 1 122). 

Examiner has pointed out particular references contained in the prior arts of record in the 
body of this action for the convenience of the applicant. Although the specified citations are 
representative of the teachings in the art and are applied to the specific limitations within the 
individual claim, other passages and figures may apply as well. It is respectfully requested 
from the applicant, in preparing the response, to consider fully the entire references as 
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potentially teaching all or part of the claimed invention, as well as the context of the passage 
as taught by the prior arts or disclosed by the examiner 
(10) Response to Argument 

As per independent claims 1 and 7, Appellant's arguments section of the brief pages 1 1 
and 12 again summarizes aspects of the invention. On page 13 of the brief. Appellant 
"acknowledges that Venkatesan may teach a software licensing rtiechanism, the association of a 
public and private key pair with a software publisher, and a publisher cryptographically signing a 
license in response to a license the [sic] request." "However, despite these teachings, [Appellant 
argues] Venkatesan fails to address the security of the license request and resulting license (Brief 
p. 13)." 

First, Appellant contends "although Venkatesan may teach creating a first public and 
private key pair and a second public and private key pair, Venkatesan fails to teach or suggest 
combining the authorization program with a software program" to issue a license upon 
invocation as per claims 1 and 7. Id. The cited reference discloses that the target object intended 
for download "may constitute an active software object, such as an executable program (column 
11, lines 8-10)." In order to access the "locked" file, upon initiation of a download, a request to 
obtain a license certificate is facilitated to obtain the embedded watermark value and allow the 
DRM system to unlock the file (column 11, lines 14-41; column 36, lines 43-56). 

In response to Appellant's argument on page 14 of the brief that "because the generation 
of the license request is manually initiated by the user interacting with the PC through a Web 
browser," the reference fail to show certain features of Appellant's invention, it is noted that the 
features upon which Appellant relies (i.e., automatic initiation of a license request without user 
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interaction) are not recited in the rejected claim(s). Although the claims are interpreted in light 
of the specification, limitations from the specification are not read into the claims. See In re Van 
Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). Regardless, the cited reference as 
discussed above provides an alternative embodiment "[w]ith respect to active objects, i.e., 
executable programs, the enforcer is preferably situated within an operating system itself 
executing in the client PC (column 14, lines 52-54)." 

Appellant further contends that the "enforcer" in the cited reference "cannot be 
considered analogous to the authorization program (Brief at pp. 14-15)." As illustrated in Figure 
8 step 870, the publisher is merely responding to a request from client PC to download a copy of 
the object and embeds a unique fingerprint into the object and disseminates it to the user without 
a request for a license or the enforcer. "Rooted in this self-authentication, the 0/S then continues 
to load and validate other blocks of code (including device drivers to be executed, DRM system 
456 and enforcer 600, as well as, where appropriate, authenticating enforcer 600' and 
establishing a trust relationship with it). See column 20, lines 9-14. Thus, the downloaded 
object with the embedded fingerprint upon invocation generates the license request which is 
followed by license issuance, verification and eventually enforcement. 

Second, Appellant concedes "although Venkatesan may teach the use of a publisher key, 
Venkatesan also fails to teach of suggest associating a product private key and public key with 
the software product (Brief at p. 15)." As illustrated in Figure 8 of Venkatesan, the publisher 
embeds a unique fingerprint into each copy of n watermarks associated with the object including 
a publisher (vendor) identification (a certified public key PKvid) and a product identification 
key (PID) (column 13, lines 25-34, column 14, lines 31-34). As detailed in Venkatesan, "to use a 
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protected object the license must pass through the verifier 620 which will first verify the 
signature in the license, then extract the rights vector, PID value and the synmietric encryption 
key (column 23, lines 1-22; column 24, lines 9-46 - please note that "secret key" is synonymous 
with private key). As is well known in the cryptographic art and disclosed in the background of 
the reference, "[d]epending on the specific cipher used, this secret can be, e.g., a simple key 
known only to a sender and a recipient, or can be a private key of a public/private key pair 
(column 3, lines 37-48; emphasis added)." The cited reference discloses that a "secret value" 
that may represent a public/private pair key would be associated with the software certificate (see 
columns 5-8; figure 5 and associated text). 

Appellant further argues "Venkatesan's secret key is symmetric, i.e., there is only one 
rather than "a product private key and public key" as claimed (Brief at p. 15)." Indeed the key 
pair claimed and discussed above includes the secret key and the publisher public key. 

Moreover, Appellant concedes that Venkatesan provides product identification (PID) and 
a certified public key but argues that the PID is indicated to be a value rather than a key. Id. As 
indicated on column 24, line 24, the PID is ia product identification value that forms a portion of 
the watermark in the object, the watermark keys being (VID, PID). 

Appellant fiirther argues "Venkatesan also fails to address providing security for the 
license request" since it "fails to teach or suggest digitally signing the license request (Brief at p. 
16)." This contention is without merit since Figure 5, clearly indicates that the license request 
545 is signed 555 by the publisher before being transmitted to the client. 

Appellant contends that the cited reference fails to disclose a "chaining of certificates 
(Brief at p. 16)." On the contrary, Venkatesan discloses, "[a]t run time, the key manager, in 
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turn, checks integrity of all other critical components of enforcer 600 using digital signatures of 
their expected vendors. To achieve this, 0/S 454 can utilize an authenticated boot process to 
assure its own security and then establish necessary chains of trust among various components of 
the 0/S and particularly throughout enforcer 600 and DRM system 456 (column 19, lines 25- 
56)." 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 




Primary Ex 
Art Unit 3621 



Conferees : 

Andrew Fischer, SPE 3621 
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